fix(pkg): vendored 头输给宿主机 —— compat.ffmpeg / compat.catch2 - #183

#183 修的两个包(compat.ffmpeg 的 -idirafter 排在系统目录之后、compat.catch2
漏 #include <new>)在这份 CI 里一直是绿的,不是因为它们对,而是因为这份 CI
结构上看不见它们:

  * mcpp 在 linux 的默认工具链是 gcc,而它通过 --sysroot 进 xlings subos 编
    译 —— 那里的 /usr/include 干干净净,宿主机的头根本不在搜索路径上。
  * 就算换了工具链,GitHub runner 的 /usr/include 里也没有 libav*,-idirafter
    没有东西可输。

所以这条腿要同时改两件事才有意义:换 llvm(无 sysroot),并真的把 ffmpeg 的
dev 头装上。只做前者,本次这个 bug 照样照不出来。

## 矩阵

emit() 多一个 toolchain 维度,linux 发两次(default + llvm),macos / windows
保持 default。job 名只在非 default 时才带工具链后缀,所以既有 job 名不变。

成本是实打实的:linux 从 3 个 shard 变 6 个,而实测 linux runner 并发是 3,
所以第二条腿是排在第一条后面跑,full run 的 linux 墙钟大致翻倍。要调的话
杠杆在 shards_for 上面那段注释里。

## 三处必须跟着改的地方

  * registry / toolstore 缓存键加 matrix.toolchain。两条腿的 runner.os 都是
    Linux,而缓存装的是工具链和编译好的 compat 包 —— 共用一个条目会让 gcc
    的产物替 llvm 回答,正好抹掉这条腿存在的理由。
  * timings artifact 名加 toolchain。upload-artifact@v4 拒绝重名,不加的话两
    条腿会抢 `timings-linux-0`,第二个直接把 job 弄失败。
  * member-timings.tsv 只吃 default 腿。llvm 腿跑的是同一批成员,把每条腿都
    glob 进去会让每个 (platform, member) 出现两行(sort -u 留不住,秒数不
    同),而 shards_for 是把匹配行全加起来的 —— linux 的工作量会读成约两倍,
    shard 数被永久顶到上限。step summary 里则按腿分别列,两条腿是不同的构建,
    平均它们谁也不描述。

## 已知会红

catch2-v2-main 在装了系统 Catch2 v3 的机器上会失败:catch2_main.cpp 用
__has_include(<catch2/catch_all.hpp>) 判 v2/v3,这个探测同样会落到系统目录。
GitHub runner 不装 catch2,所以这条腿上它是绿的(实测 #183 的 CI:linux /
macos / windows 三平台 catch2-v2-main 全 ok)。真要修得等 per-version build
blocks(mcpp#290)。

本地只在 llvm 下取样跑了 19/60 个成员,其余 41 个(grpc / protobuf / godot /
llamacpp / openssl 等重型)受本机磁盘所限没跑 —— 这条腿的第一轮就是它们第一
次在 linux 上被 llvm 编译,可能还有别的既有问题被照出来。刻意不加
continue-on-error:一条非阻塞的腿很容易被永久无视,和一条长期红的腿是同一种病。

`catch2_main.cpp` 用 `__has_include(<catch2/catch_all.hpp>)` 区分两个大版本。
这个探测同样会翻系统 include 目录,而 catch_all.hpp 正是每个发行版的 catch2
包都会装的头。于是在一台装了系统 Catch2 v3 的机器上,一个 v2 消费者被回答
"你是 v3",编出 Catch::Session 那条入口,再死在链接:

    ld.lld: error: undefined symbol: Catch::Session::Session()
    >>> referenced by /usr/include/catch2/catch_session.hpp:39

和 #183 修的 compat.ffmpeg 是同一类问题:宿主机装了同名开发包,vendored 的
东西就被挤掉。gcc 不中招是因为它通过 --sysroot 进 xlings subos,那里没有
/usr/include/catch2 —— 所以这条在 CI 和默认工具链下一直是绿的。

改成探测 `catch2/catch_user_config.hpp.in`:上游把它作为 CMake 模板放在 v3
的源码树里,装的是生成后的 .hpp,模板本身从不安装。三种情形在 clang 22.1.8
和 gcc 16.1.0 上都验过:

    vendored v3 在 -I 上   -> v3     (两种探测一致)
    vendored v2 在 -I 上   -> v2     (catch_all.hpp 答 v3,即本 bug)
    只有系统 v3            -> v2     (catch_all.hpp 答 v3)

四个 catch2 成员 × 两个工具链,在一台装了系统 Catch2 v3 的机器上全过 ——
catch2-v2-main 此前在 llvm 下是 FAIL。

#183 的描述里把这条列为"要等 per-version build blocks(mcpp#290)才能修",
那个判断下早了:要的不是"知道自己是哪个版本",只是一个系统装不出来的探针。
mcpp#290 仍然是更干净的答案,它让这个问题整个消失,而不是换一个探针。